Is there a reason why we cannot have the container as part of the return value of the browsingContext.getTree command? It would be somewhat similar to the clientWindow field.

Yes, that API currently does not include any shared references from script and would not allow expressing the ownership of the returned DOM element.

To clarify: we could probably plumb it via the getTree along with the other options we might need to define how to return the element but to me it looks like locateNodes is a better place compared to the getTree.

I think there's a slight misconception here: sharedId for nodes doesn't depend on ownership. locateNodes also doesn't provide a way to set the ownership. I broadly think that's fine for this API; it doesn't seem more useful to hold a reference to the container element than the Window itself.

Hm, when I was reviewing the locateNodes PR I recall there was the ownership parameter but indeed I do not see it after checking now. If we were to use the locateNodes for things other than a11y in Puppeteer, we would definitely need the ownership param to match the existing behavior.

Alright, I recall now: so in CDP we retain the resulting collection and not nodes individually so that is still different to the API here.

The WebDriver model to this point is that the sharedId for a node is just an intrinsic property of the node, and returning it doesn't affect the lifetime of the node in any way. executeScript and friends also provide a way to take (shared) ownership of the (currently only root) return value.

We already have lots of APIs that return objects without providing any way to take ownership of them (notably anything returning a context). I don't immediately see why you'd need to take ownership of an iframe element with this kind of API; if something removes the iframe from the DOM you're probably in an unexpected state even if you still have a reference to the js object.

Anyway, I don't have a really strong opinion here, but if clients ~always want to know which iframe owns a nested browsing context, I think that getTree would work. If it's a rarer requirement, or there really is a strong use case for taking ownership of the iframe itself, then using either a separate command or a locator could work.